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Abstract 


For scalability purposes, a network may comprise multiple Interior 
Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label 
Switched Path (TE-LSP) is an LSP that transits through at least two 
IGP areas. In a multi-area network, topology visibility remains 
local to a given area, and a head-end Label Switching Router (LSR) 
cannot compute an inter-area shortest constrained path. One key 
application of the Path Computation Element (PCE)-based architecture 
is the computation of inter-area TE-LSP paths. The PCE Communication 
Protocol (PCECP) is used to communicate computation requests from 
Path Computation Clients (PCCs) to PCEs, and to return computed paths 


in responses. This document lists a detailed set of PCECP-specific 
requirements for support of inter-area TE-LSP path computation. It 
complements the generic requirements for a PCE Communication 
Protocol. 
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1. Introduction 


[RFC4105] lists a set of motivations and requirements for setting up 
TE-LSPs across IGP area boundaries. These LSPs are called inter-area 
TE-LSPs. These requirements include the computation of inter-area 
shortest constrained paths with a key guideline being to respect the 
IGP hierarchy concept, and particularly the containment of topology 
information. The main challenge with inter-area MPLS-TE lies in path 


computation. Indeed, the head-end LSR cannot compute an explicit 
path across areas, as its topology visibility is limited to its own 
area. 


Inter-area path computation is one of the key applications of the 
PCE-based architecture [RFC4655]. The computation of optimal inter- 
area paths may be achieved using the services of one or more PCEs. 


Such PCE-based inter-area path computation could rely for instance on 
a single multi-area PCE that has the TE database of all the areas in 
the IGP domain and can directly compute an end-to-end constrained 
shortest path. Alternatively, this could rely on the cooperation 
between PCEs whereby each PCE covers one or more IGP areas and the 
full set of PCEs covers all areas. 
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The generic requirements for a PCE Communication Protocol (PCECP), 
which allows a PCC to send path computation requests to a PCE and the 
PCE to send path computation responses to a PCC, are set forth in 
[RFC4657]. The use of a PCE-based approach for inter-area path 
computation implies specific requirements on a PCE Communication 
Protocol, in addition to the generic requirements already listed in 
[RFC4657]. This document complements these generic requirements by 
listing a detailed set of PCECP requirements specific to inter-area 
path computation. 


It is expected that PCECP procedures be defined to satisfy these 
requirements. 


Note that PCE-based inter-area path computation may require a 
mechanism for automatic PCE discovery across areas, which is out of 
the scope of this document. Detailed requirements for such a 
mechanism are discussed in [RFC4674]. 

2. Terminology 
LSR: Label Switching Router. 
LSP: MPLS Label Switched Path. 
TE-LSP: Traffic Engineered Label Switched Path. 


IGP area: OSPF area or IS-IS level. 


ABR: IGP Area Border Router, a router that is attached to more than 
one IGP area (ABR in OSPF or L1/L2 router in IS-IS). 


Inter-Area TE-LSP: TE-LSP that traverses more than one IGP area. 
CSPF: Constrained Shortest Path First. 

SRLG: Shared Risk Link Group. 

PCE: Path Computation Element: an entity (component, application or 
network node) that is capable of computing a network path or route 


based on a network graph and applying computational constraints. 


PCC: Path Computation Client, any application that request path 
computation to be performed by a PCE. 


PCECP: PCE Communication Protocol, a protocol for communication 
between PCCs and PCEs, and between PCEs. 
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ERO: Resource Reservation Protocol (RSVP)-TE Explicit Route Object. 
It encodes the explicit path followed by a TE-LSP. 

2.1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Motivations for PCE-Based Inter-Area Path Computation 


IGP hierarchy enables improved IGP scalability by dividing the IGP 
domain into areas and limiting the flooding scope of topology 


information to within area boundaries. A router in an area has full 
topology information for its own area, but only information about 
reachability to destinations in other areas. Thus, a head-end LSR 


cannot compute an end-to-end path that crosses the boundary of its 
IGP area(s). 


A current solution for computing inter-area TE-LSP path relies on a 
per-domain path computation [PD-COMP]. It is based on loose hop 
routing with an ERO expansion on each ABR. This allows an LSP to be 
set up following a constrained path, but faces two major limitations: 


- This does guarantee the use of an optimal constrained path. 


- This may lead to several crankback signaling messages and hence 
delay the LSP setup, and may also invoke possible alternate routing 
activities. 


Note that, here, by optimal constrained path we mean the shortest 
constrained path across multiple areas, taking into account either 
the IGP or TE metric [RFC3785]. In other words, such a path is the 
path that would have been computed by making use of some CSPF 
algorithm in the absence of multiple IGP areas. 


The PCE-based architecture [RFC4655] is well suited to inter-area 
path computation. It allows the path computation limitations 
resulting from the limited topology visibility to be overcome by 
introducing path computation entities with more topology visibility, 
or by allowing cooperation between path computation entities in each 
area. 
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There are two main approaches for the computation of an inter-area 
optimal path: 


- Single-PCE computation: The path is computed by a single PCE that 
has topology visibility in all areas and can compute an end-to-end 
optimal constrained path on its own. 


- Multiple-PCE computation with inter-PCE communication: The path 
computation is distributed on multiple PCEs, which have partial 
topology visibility. They compute path segments in their domains 
of visibility and collaborate with each other so as to arrive at an 
end-to-end optimal constrained path. Such collaboration is ensured 
thanks to inter-PCE communication. 


Note that the use of a PCE-based approach to perform inter-area path 
computation implies specific functional requirements in a PCECP, in 
addition to the generic requirements listed in [RFC4657]. These 
Specific requirements are discussed in the next section. 


4. Detailed Inter-Area Specific Requirements on PCECP 
This section lists a set of additional requirements for the PCECP 


that complement requirements listed in [RFC4657] and are specific to 
inter-area (G)MPLS-TE path computation. 


4.1. Control and Recording of Area Crossing 


In addition to the path constraints specified in [RFC4657], the 
request message MUST allow indicating whether or not area crossing is 
permitted. Indeed, when the source and destination reside in the 
same IGP area, there may be intra-area and inter-area feasible paths. 
As set forth in [RFC4105], if the shortest path is an inter-area 
path, an operator either may want to avoid, as far as possible, 
crossing areas and thus may prefer selecting a sub-optimal intra-area 
path or, conversely, may prefer to use a shortest path, even if it 
crosses areas. 


Also, when the source and destination reside in the same area it may 
be useful to know whether the returned path is an inter-area path. 
Hence, the response message MUST allow indicating whether the 
computed path is crossing areas. 
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4.2. Area Recording 


It may be useful for the PCC to know the set of areas crossed by an 
inter-area path and the corresponding path segments. Hence, the 
response message MUST allow identifying the crossed areas. Also, the 
response message MUST allow segmenting the returned path and marking 
each segment so that it is possible to tell which piece of the path 
lies within which area. 


4.3. Strict Explicit Path and Loose Path 


A Strict Explicit Path is defined as a set of strict hops, while a 
Loose Path is defined as a set of at least one loose hop and zero, 
one or more strict hops. An inter-area path may be strictly explicit 
or loose (e.g., a list of ABRs as loose hops). It may be useful to 
indicate to the PCE if a Strict Explicit path is required or not. 
Hence, the PCECP request message MUST allow indicating whether a 
Strict Explicit Path is required/desired. 


4.4. PCE List Enforcement and Recording in Multiple-PCE Computation 


In case of multiple-PCE inter-area path computation, a PCC may want 
to indicate a preferred list of PCEs to be used, one per area. In 
each area, the preferred PCE should be tried before another PCE is 
selected. Note that if there is no preferred PCE indicated for an 
area, any PCE in that area may be used. 


Hence, the PCECP request message MUST support the inclusion of a list 
of preferred PCEs per area. Note that this requires that a PCC in 
one area has knowledge of PCEs in other areas. This could rely on 
configuration or on a PCE discovery mechanism, allowing discovery 
across area boundaries (see [RFC4674]). 


Also, it would be useful to know the list of PCEs that effectively 
participated in the computation. Hence, the request message MUST 
support a request for PCE recording, and the response message MUST 
support the recording of the set of one or more PCEs that took part 
in the computation. 


It may also be useful to know the path segments computed by each PCE. 
Hence, the request message SHOULD allow a request for the 
identification of path segments computed by a PCE, and the response 
message SHOULD allow identifying the path segments computed by each 
PCE. 
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4.5. Inclusion of Area IDs in Request 


Knowledge of the areas in which the source and destination lie would 
allow a PCE to select an appropriate downstream PCE. This would be 
useful when the area ID(s) of a PCE (i.e., the area(s) where it has 
visibility) is/are known, which can be achieved by the PCE Discovery 
Protocol (see [RFC4674]) or by any other means. 


A PCE may not have any visibility of the source/destination area and 
hence may not be able to determine the area of the 


source/destination. In such a situation, it would be useful for a 
PCC to indicate the source and destination area IDs in its request 
message. 


For that purpose, the request message MUST support the inclusion of 
the source and destination area IDs. Note that this information 
could be learned by the PCC through configuration. 


4.6. Area Inclusion/Exclusion 


In some situations, it may be useful for the request message to 
indicate one or more area(s) that must be followed by the path to be 
computed. It may also be useful for the request message to indicate 
one or more area(s) that must be avoided by the path to be computed 
(e.g., request for a path between LSRs in two stub areas connected to 
the same ABR(s), which must not cross the backbone area). Hence, the 
request message MUST allow indicating a set of one or more area(s) 
that must be explicitly included in the path, and a set of one or 
more area(s) that must be explicitly excluded from the path. 


4.7.  Inter-Area Diverse Path Computation 


For various reasons, including protection and load balancing, the 
computation of diverse inter-area paths may be required. There are 
various levels of diversity in an inter-area context: 


- Per-area diversity (intra-area path segments are link, node, or 
SRLG disjoint) 


- Inter-area diversity (end-to-end inter-area paths are link, 
node, or SRLG disjoint) 


Note that two paths may be disjoint in the backbone area but non- 
disjoint in peripheral areas. Also two paths may be node-disjoint 
within areas but may share ABRs, in which case path segments within 
an area are node-disjoint, but end-to-end paths are not node 
disjoint. 
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The request message MUST allow requesting the computation of a set of 
inter-area diverse paths between the same node pair or between 
distinct node pairs. It MUST allow indicating the required level of 
diversity of a set of inter-area paths (link, node, and SRLG 
diversity), as well as the required level of diversity of a set of 
intra-area segments of inter-area paths (link, node, and SRLG 
diversity) on a per-area basis. 


The response message MUST allow indicating the level of diversity of 
a set of computed inter-area loose paths (link, node, and SRLG 
diversity), globally, and on a per-area basis (link, node, and SRLG 
diversity of intra-area path segments). 


Note that, in order to ensure SRLG consistency, SRLG identifiers 
within the IGP domain should be assigned and allocated by the same 
entity. 


Note that specific objective functions may be requested for diverse 
path computation, such as minimizing the cumulated cost of a set of 
diverse paths as set forth in [RFC4657]. 


4.8.  Inter-Area Policies 


In addition to the policy requirements discussed in [RFC4657], the 
application of inter-area path computation policies requires some 
additional information to be carried in the PCECP request messages. 
The request message MUST allow for the inclusion of the address of 
the originating PCC. This may be useful in a multiple-PCE 
computation, so as to apply policies not only based on the PCECP peer 
but also based on the originating PCC. 


Note that work on supported policy models and the corresponding 
requirements/implications is being undertaken as a separate work item 
in the PCE working group [PCE-POL-FMWK]. 


4.9. Loop Avoidance 
In case of multiple-PCE inter-area path computation, there may be 


risks of PCECP request loops. A mechanism MUST be defined to detect 
and correct PCECP request message loops. This may rely, for 
instance, on the recording, in the request message, of the set of 
traversed PCEs. 


Also, the returned path in a response message MUST be loop free. 
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5. 


8. 


Manageability Considerations 


The inter-area application implies some new manageability 
requirements in addition to those already listed in [RFC4657]. The 
PCECP PCC and PCE MIB modules MUST allow recording the proportion of 
inter-area requests and the success rate of inter-area requests. The 
PCECP PCC MIB module MUST also allow recording the performances of a 
PCE chain (minimum, maximum, and average response times), in case of 
multiple-PCE inter-area path computation. 


It is really important, for diagnostic and troubleshooting reasons, 
to monitor the availability and performances of each PCE of a PCE 
chain used for inter-area path computation. Particularly, it is 
really important to identify the PCE(s) responsible for a delayed 
reply. 


Hence, a mechanism MUST be defined to monitor the performances of a 
PCE chain. It MUST allow determining the availability of each PCE of 
the chain as well as its minimum, maximum, and average response 
times. 


Security Considerations 


IGP areas are administrated by the same entity. Hence, the inter- 
area application does not imply a new trust model or new security 
issues beyond those already defined in [RFC4657]. 
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